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File Futures 



FIELD OF THE INVENTION 

The present invention relates to method and system for transferring data through a computer 
network. In particular, it relates to improvements in transferring large data amounts e.g., large 



BACKGROUND OF THE INVENTION 

Q The present inventions is applicable to any situation in which large amounts of data have to be 
12 transferred to a computer network. It has particular effects and improvements in the field of 
M= streaming 'new media' data such as audio and video data as it is increasingly required in business 



f fi New media data extends traditional computer data formats into more natural data formats for the 
f interaction of humans and computers by incorporating images, motion pictures, voice, audio, and 
f 3 video. Leading market, business, social, and technical indicators point to the grov^ng importance 

of this digitally recorded content. Latest in 2003, new media data will ecUpse structured data in 
15 sheer volume. 

One of the key problems with new media data is transferring the usually huge amounts of content 
through a network. Normally, data is transferred using the store&forward paradigm, e.g. the 
complete content is transferred before anything is done with the data. A prominent 
implementation of this paradigm is the File Transfer Protocol (FTP), the standard way to transfer 
20 files throughout the World Wide Web. 



5 



files. 



processes and with increasing acceptance of the Intemet. 
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For conventional data this works fine, as the amounts of data to be transferred are comparably 
small. For audio and video clips though, the latency time that passes between a request for 
rendering and the start of the rendering becomes unpractically long. 

For this reason, in recent years a second paradigm called streaming has emerged. Streaming 
allows the rendering of the media to take place in parallel with the transfer of its content, which 
reduces latency times to a minimum. Streaming software always operates in pairs, a stream server 
pumping the data continuously through the network and a stream player receiving the data and 
rendering it. 

Unfortunately, the way streaming is performed today has some serious side effects. First of all, the 
direct coupling of data transfer and doing something with the transferred data makes current 
streaming technology only available for special purposes, like rendering. Also, there are 
differences in handling streaming compared to store&forward, Uke the requirement of providing 
metafiles instead of the media itself, or different and proprietary security means. 

3 Further, the correlation between stream server and renderer has led to proprietary protocol 
5 add-ons being transferred between them two for tactical reasons, practically preventing the player 
y products of manufacturer A to work together with the stream server products of manufacturer B 
and vice versa. 

Further, prior art streaming technology is restricted to stream data which are stored on the same 
computer device in which the stream server in use is residing. This, however, prevents streaming 
from being accomplished fi-om any proprietary data server, as e.g., a DB2 database acting as 
source of the data stream. This reveals a considerable disadvantage as there is thus a practical 
constraint to store business relevant data on the streamer hardware platform instead on a higher 
quality computer system with an increased degree of data security. 

SUMMARY OF THE INVENTION 

It is thus an object of the present invention to alleviate the disadvantages caused by proprietary 
streamer/player pairs. 
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The present invention provides for transparently minimizing latency times that come with 
traditional file transfer in a store&forward manner: 




The present invention decouples the transfer and the rendering of media in a way that combines 
the strength, i.e., the advantages of the streaming paradigm v^th the flexibiKty and usability 
5 advantages of the store&forv^ard paradigm. 

The basic novel principles are referred to herein as Tile Futures' and 'Future FTP' since an 
application, e.g., a renderer or player of new media data which uses the novel principles can first 
initiate the transfer of the needed file through a novel method replacing standard FTP and - while 
the file is being transferred - is enabled to already start working on the "fixture content" of the file 
1 0 currently being transferred. 

This is basically achieved by separating the application logic from the transport logic. The 
li^ transfer/transport logic is covered by a novel transfer protocol whereas the player application 
.u logic can issue standard file access statements like fread, fseek in order to access and render the 

streamed data. 

|5 The present invention provides for two parts, a Future client/server pair providing file transfer 
ry services as e.g., like FTP and a Future File System Extension. These two parts communicate via 
It an open interface which is able to be standardized. This implementation of the Future FTP 
C3 client/server pair and the Future File System Extension can be supplied by different parties. 

The Future FTP cUent/server pair can use streaming technology and/or standard store and 
20 forward technology to perform the transfer. If streaming is used though, the necessary additional 

parameters such as required bandwidth may not show up in the Future FTP client interface. 

Instead, they can either be provided by a separate system management interface, for example a 

configuration file, or, they can be determined on the fly by interpreting the source file content. 

Optional qualities of service such as a bandwidth reservation through the resource reservation 
25 protocol (RS VP) can be applied transparently. 
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The Future FTP client interface follows the standard, and the extension necessary for the 
interaction with the Future File System Extension is able to be standardized, too. 

In contrary to normal, i.e., prior art files, the novel File Futures allow the content of a file to be 
read while parts of it are still transferred, therefore hiding the fact that the file is not completely 
5 available yet. For this reason, a file future knows it's related Future FTP CUent instance through a 
callback interface mechanism. 

For the scope of the present invention it is assumed that while the transfer of a future file is in 
progress no application is allowed to write to that file. Once the transmission is completed the 
relationship of the Future File System Extension to the Future FTP client for that session is 
10^ dissolved and later access requests to the transferred file are treated as usual prior art file 
."5 requests. This imphes that write access to that file is allowed fi*om that time on. 

Y! The File Future File System Extension provides a mechanism to allow recovery fi-om broken FTP 

is ^ 

i 3 transfers as otherwise an application cannot be sure if a transfer really completed due to it's 
asynchronous nature. In other words, the Future File System Extension is able to reinitiate 
1 transfers in effect to guarantee that a transfer completes successfully. 

15 File Futures are intended as a replacement for all means of FTP file transfer paradigms and have 
Q the advantage of transparently minimizing latency times for accessing the required file content. It 
can therefore be used in all application areas where applications do not work on the complete file 
content, but instead only use sections of a file at a time. Examples for these kinds of appUcations 
20 are: 

Rendering applications like video and audio players. Using the File Future technology will make 
proprietary stream server products obsolete to a high degree, as all media players can render using 
standard file access. 

CAD/CAM apphcations profit because they're usually designed in a way to work on smaller 
25 portions of a file at a time due to huge size of CAD/CAM files. Therefore, using the novel File 
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Future technology will give CAD/CAM products advantages similar to the advantages which 
media renderers gain today from using streaming. 

The novel technology can be advantageously exploited to integrate proprietary stream servers into 
an enterprise network. 

5 These and other objects will be apparent to one skilled in the art from the following drawings and 
detailed description of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

'^i The present invention is illustrated by way of example and is not limited by the shape of the 
J figures of the accompanying drawings in which: 

b ■ - 
L A. 

fiS Fig. 1 is a schematic block diagram showing die most essential elements in a distributed 

1 3 system which is used for the present invention according to one preferred aspect thereof as 

well as the basic activities during the novel client-server file transfer method, 

s ^ 

=; ; s 

i J 

Fig. 2 is a so-called Unified Modeling Language (UML) Sequence Diagram showing the 
f j most essential steps and the most essential processes operating in parallel of the overall 

15 control flow according to one aspect of the novel file transfer method, and 

Fig. 3 is a schematic block diagram of a variation of Fig. 1, showing a system structure 
which is also able to be realized according to a second preferred aspect of the novel file 
transfer method. 

20 DESCRIPTION OF THE PREFERRED EMBODIMENT 
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With general reference to the figures and with special reference now to Fig. 1 a preferred basic 
configuration according to a first preferred aspect of the present invention depicted in Fig. 1 is 
described in more detail. 

An insurance company has a data server 10 using a conventional file system 12 in order to store 
5 business-relevant data. Some of the data is stored in form of video films consuming large amounts 
of bytes as, e.g., several himdreds of megabytes. Said data server 10 is connected to a novel 
server transfer component 14 and a high speed data transmission line 15 connecting to a number 
of client computer systems one of which is depicted with reference sign 30. The client computer 
system is now assumed to be a PC associated to some staff of said insurance company, acting as 
10 an end-user with reference to the present invention's file transfer and rendering method. 

n Said novel server software component 14 acts as a sender component for transferring files of the 

file system 12 to said predetermined client target computer systems 30. As said component 14 
in forms part of the novel file future concepts it is referred to herein as future FTP server and will be 

'~ abbreviated as FFTP server 14. 

^ =^ 

1 _i 

1^ On the client computer side according to some basics of the novel concepts there is implemented 
if. an additional program component which cooperates with the end-user PC's file system 24 and 
f y acts as a file system extension 22. As said additional software component is concerned with the 
1% novel provision of the above mentioned file futures said component 22 is referred to herein as 
Future File System Extension and abbreviated as FFSE. As it will be described in more detail 
20 below said file system extension helps to decouple the file access operations from the file transfer 
operation. Said FFSE component 22 is arranged to cooperate with a further novel software 
component 18. 

Said component 18 acts as a file transfer client program. As it forms part of the novel file future 
concepts it is referred to herein as Future FTP client and abbreviated herein as FFTP client. In 
25 particular, said FFTP client 1 8 acts as a receiver program for files which are transferred from the 
ftiture FTP server 14 associated with the data server 10 mentioned above. 
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Further, said end-user PC is provided with a player program 32 which is capable to render video 
data and/or audio data which is received from the FFTP server 14. 

When the end-user associated with PC system 30 wants to render data on his PC, the data, 
however, residing in the remote data server 10 he initiates an inventive file transfer with some 
5 initializing work, issues a 'traditional' file access command to his file system by the media player 
like 'read' and 'seek' and will be able to render the data although the transfer has not yet being 
completed In particular, according to the present invention all file access commands as they are 
in particular read and seek commands are issued by the player 32 via an input to the file system 24 
to the FFSE component 22 for being handled in cooperation with the FFTP client 18 and FFTP 
10 server components 14. 

For more detail additional reference should now be made to Fig. 2 which is a so-called Unified 
ModeHng Language (UML) Sequence Diagram showing the parallel cooperation between the 
W three essential components of the novel method, as they are the application 20, the FFTP chent 
= 18, and the FFTP Server 14, Time increases from top to down. Circle-like arrows are symbols 
Ipjl indicating the beginning and the end of a loop, respectively. 

li As it is recognizable at the first glance the novel method starts user-initiated by an apphcation call 
(top right comer) followed by some initialization work performed by the FFTP client 1 8 and then 
splits up into three parallel activities symbolized with a respective time column where the left most 
column mostly operates when requested by the FFTP client until it is terminated by the end-user, 
20 again, which is not depicted explicitly. 

In particular, said application 20 first initiates a Future FTP transfer, passing the file name of the 
remote source file and the file name of the local target file to the FFTP client 18. This can be 
done in the same syntax as in standard FTP, step 205. 
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Then, in a step 210 said FFTP client 18 creates a file future, i.e., calls the FFSE component 22 to 
create a local target file within the client file system 24. For doing that a prior art file creating 
command like 'fopen' with 'create' attributes set is used. 

For improved clarity, it should be noted that the terms 'file fixture' and 'target file' refer to the 
5 same physical data object which is in deed a prior art file as an element of a file system. Those two 
different terms are used, however, in order to disclose the real core of the present invention to 
handle a file with prior art file access commands transparent to the application while the file is not 
yet 'complete' and therewith ready to be accessed in prior art technology. 

j=-b Then, in a step 215, the FFTP chent registers a prior art callback with the help of the novel Future 
|| File System Extension for the control flow to be expected, e.g., via passing a process ID or a port 
=S niunber to the FFSE. 

f 3 Thereafter, it initiates the asynchronous transfer of the file content with the Future FTP server, 
step 220. In response thereto, the FFTP server component 14 opens the source file for read 
access, step 225 which results in the requested bytes being transferred over the network. Finally, 

?§ the application FFTP client call returns to the application, step 226. 

C3 

Then, application 20 for example calls a media player 32 which opens the target file, step 227, and 
is able to access them, i.e. to render it while it is still being transferred. In general, the 
user-initiated file access calls like 'ft*ead' and 'fseek' received by the file system 24 are routed to 
the novel Future File System Extension 22 for special behavior. 

20 This can generally be realized for example by the technique of stacking file systems or using the 

XDSM technology. Further, it is possible to enrich the code of a file system which is open to 

application programmers as it is e.g., the LINUX file system with a kind of wrapper logic which 

implements the above described mechanism, i.e., to catch the relevant file access commands 

issued by the application and to route it to the FFTP client for fiirther processing, or simply pass it 
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to another FFTP process running in the same computer device or, in general, to any location as it 
is required for the actual streaming process. 

Thus, in a step 235 the FFTP client requests the next bytes to be transferred from the FFTP 
server. This request is satisfied by the FFTP server component 14 by reading from the server file 
5 system 12 from let's say the current read position, step 237. Those bytes are stored to the file 
future, step 239, and the application is able to read it from the target file, step 240. When data is 
already received from the network it can be rendered, and if not yet - it waits until it is arrived 
completely, step 250. In a manner Uke that an end-user can for example display a video clip from 
its actual beginning on his screen. 

M As long as the whole file transfer, i.e., the whole video clip transfer between said FFTP server 
component 14 and the FFTP cUent 18 is not yet completed, as it can generally be the case with a 
large amount of data to be transferred the novel concept depicted in the center and lower part of 

%j Fig. 2 provides for 'random access' of data while the data requested before is still being 

f 1 

I" transferred: 

l^a In a step 252, for example, the end-user may wish to skip a certain portion of the video clip 

because he is not interested in watching it. Thus, it is assumed that he jumps to the middle portion 

r : 

■a 

of the video clip and operates the media player 32 installed on his PC correspondingly. A file read 
access request comprising an instruction to reposition the read position in the source file at the 
server 12 corresponding to the player operation command is thus input to the file system. There it 
20 is caught by the FFSE component 22 in order to forward it - step 255 - via the FFTP client 1 8 to 
the FFTP server component 14. Thus, the read position for reading the source file of the video 
clip is actually repositioned in a step 260 and the data stream is continued beginning with the 
desired new position. 
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Of course, this means that the file pointer on the target file system at the client PC 30 is also 
repositioned to the new location which generally will result in "holes" in the target file. 

If the filling of the holes is desired as it is expected to be in most cases this can be handled by the 
FFTP cUent 1 8 by recursively filling them automatically once it has transferred to the file end, step 
265. This way of proceeding, i.e., sequentially streaming and concurrently rendering the cHent- 
requested data while being ready for promptly serving any end- user requested jumps to a newly 
preferred read position may be continued as long as desired by the end-user, step 270. 

Thus, the present invention provides for a very effective media player operation in which the 
end-user is provided with a quick random access to the desired data. 

According to the preferred novel embodiment shown in Fig. 1 and the flow of operation shown in 
Fig. 2 any prior art stream server becomes obsolete which saves costs and has the effect that the 
data to be rendered at the end-user PC 30 may be transferred directly from the data server 10 
through the network to the end- user PC 30. Thus, the data need not to be present physically at 
any third location in the network which is of special interest when business-critical data is to be 
rendered. Further, any player program can be used with this approach as the novel File Future 
concept can be implemented offering an open standard covering all players being commercially 
available. Thus, the disadvantageous effects of prior art required proprietary pairs of stream 
server/player are eliminated. 

With reference now to Fig. 3 which is a schematic block diagram illustrating a variation of Fig. 1 
a further system structure which is also able to be realized according to a second preferred aspect 
of the novel file transfer and rendering method will be described in more detail. 

The special interest of this embodiment is that the basic configuration forming a kind of 'triangle' 
and comprising a data server 10, a stream server 16, and an end-user client PC requesting and 
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rendering the new media data can be found very often in today's business environments, as well as 
in situations in which an Internet user wants to render new media data. 

The same reference numerals describe the same or functionally equivalent elements as described 
already before with reference to Fig. 1 . Thus, it should be referred to the corresponding 
description of Fig. 1 where appropriate. 

In contrast to Fig. 1 the personal computer 30 acts in Fig. 3 as an end-user client in relation to a 
prior art stream server 16 which comprises a dedicated stream server appHcation program 
component 20 in order to cooperate with a corresponding client side media player program 32 
which is capable to render video data and/or audio data received from the stream server 16. The 
end-user operates the media player application 32 which thus issues corresponding file access 
commands to the application stream server component 20 across the network. Then, the 
appHcation stream server component 20 in turn plays the same role which the media player had in 
the embodiment described with reference to Fig. 1. Thus, the end-user client PC renders media 
data streamed twice in the network: first fi-om the data server 10 to the stream server 16 via, for 
example, a high speed connection line 15, and second, from the application stream server 16 to 
the client 30. 

In general, the novel File Future principles can be positioned to both streaming technology and 
store&forward technology. Compared to streaming technology. File Futures have the advantage 
to be absolutely transparent to the application. In other words, the application still works on a 
strict file paradigm basis and does not need to be reprogrammed to be enabled to know that the 
complete file is not available at the time it tries to access it. 

Compared to traditional store&forward technology, the novel File Futures have the advantage to 
minimize the latency time, which is a use inhibitor for store&forward mechanisms when large files 
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are transferred. In effect this means that the novel concepts of File Futures combine the strength, 
i.e., the advantages of both paradigms, streaming and store&forward. 




In the foregoing specification the invention has been described with reference to a specific 
5 exemplary embodiment thereof. It v^ll, however, be evident that various modifications and 

changes may be made thereto without departing from the broader spirit and scope of the invention 
as set forth in the appended claims. The specification and drawings are accordingly to be regarded 
as illustrative rather than in a restrictive sense. 

For example, a temporary buffer could be used as an intermediate stage to store the fi'eshly 
l|k streamed/ transferred data temporarily and keep them stored until they were copied into the target 
'^3 file and/or until they were rendered by the client PC. Thus, the target file would be decoupled 

from the streaming process, and could be built asynchronously with the data transfer progress 
rV achieved by streaming or by burst transmission and store&forward technology. 

kid 

The novel approach described above can be advantageously combined with the natural 'inner' 
iBi structure of many data sources having huge contents, like books comprising many images, photo 
f[i catalogues, music pieces, films or large business data files in for example banking or CAD 
;i applications which often use a table of contents for the user to navigate quickly in the data. Thus, 
the end-user will often have the possibility to first see the table of contents for a selection of the 
desired data. Then a file access command like the above described 'seek' will usually follow - and 
20 will be supported according to the present invention with minimized latency. Basically the same 
can be done with a conventional table of indexes, as well. 

Thus, the present invention represents a large step forward for improving the performance of 
sessions in the World Wide Web where in many cases the user's strongest desire is to retrieve 
quickly what he searches for. 
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The present invention can be realized in hardware, software, or a combination of hardware and 
software. A Future File Transfer and/or Rendering tool according to the present invention can be 
realized in a centralized fashion in one computer system, or in a distributed fashion where 
different elements are spread across several interconnected computer systems. Any kind of 
computer system or other apparatus adapted for carrying out the methods described herein is 
suited. A typical combination of hardware and software could be a general purpose computer 
system with a computer program that, when being loaded and executed, controls the computer 
system such that it carries out the client or server specific steps of the methods described herein. 

The present invention can also be embedded in a computer program product, which comprises all 
the features enabling the implementation the respective steps of the methods described herein, and 
which - when loaded in one or more computer systems - is able to carry out these methods. 

Computer program means or computer program in the present context mean any expression, in 
any language, code or notation, of a set of instructions intended to cause a system having an 
information processing capability to perform a particular fimction either directly or after either or 
both of the following; (1) conversion to another language, code or notation, or (2) reproduction 
in a different material form. 

While the preferred embodiment of the invention has been illustrated and described herein, 
it is to be understood that the invention is not limited to the precise construction herein disclosed, 
and the right is reserved to all changes and modifications coming within the scope of the invention 
as defined in the appended claims. 
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